Cool idea,

formally the ACL should limit access to one cluster of the endpoint and it should also made sure that also a cluster client is defined for that on the target. Could that get added?

@Apollon77

Is it as shown in the following figure?

command like this :

const bindingEntry: BindingEntryStruct = {
    node: targetNodeId,
    endpoint: targetEndpoint,
    group: undefined,
    cluster: targetCluster,
    fabricIndex: undefined,
};

Cool idea,

formally the ACL should limit access to one cluster of the endpoint and it should also made sure that also a cluster client is defined for that on the target. Could that get added?

I think that in some cases like dimmer switch this may require pairing with several clusters, such as cluster no. 6 is the On/Off cluster and the cluster no. 8 is the Level Control cluster.
See this:
https://github.com/project-chip/connectedhomeip/tree/master/examples/light-switch-app/nrfconnect#unicast-binding-to-a-remote-endpoint-using-the-chip-tool-for-windows-or-linux

In this command:

{"fabricIndex": 1, "node": <1>, "endpoint": 1, "cluster": 6} is a binding for the On/Off cluster.
{"fabricIndex": 1, "node": <1>, "endpoint": 1, "cluster": 8} is a binding for the Level Control cluster.

Yes formally it should be mapped to "where a cluster client existing for" ... so yes having the acl for the endpoint is pragmatic solution :-)

I ran a test with the latest commit and it worked fine. I tried with 2 DK:

1. nRF5340 DK as a light
2. SL xG24 Explorer Kit as a switch

ran a test between Inovelli vtm31 white dimmer switch and aqara T2 as well Nanoleaf essentials NL67 bulbs Dimming & On/Off works from the switch paddle. Virtually controlling the Inovelli switch (on/off/dim) thru HA or Apple Home does not control bulbs though.

Cool, but be careful with the ACLs ... number of ACLs per fabric is limited. so if you needed to setup two ACLs here you already use a lot of slows on the node for the fabric. That's one of the fun parts around bindings or groups ...

@A-vesalius

Good news! What I was expecting has happened. Let's take a look at what's going on.

First, check whether the ACL of the target device has been written successfully (the ACL is located in endpoint 0 of the target device).
If the ACL is successfully written, then open the debug panel of the browser to see if the binding command has failed to execute (unexpected situations may have occurred).

Finally, in the test results I obtained, some devices do not support the binding command, even if they have the binding cluster. Based on the results of my packet capture using wireshark, they did not broadcast the on/off commands for the binding device.

@Apollon77

Yes, I have also noticed this problem. When developing with the esp-matter sdk, the device side will limit the size of the ACL/binding list.

Perhaps before executing the ACL command, it is necessary to first determine whether the corresponding conditions are met, such as obtaining the actual size of the ACL list.

@Apollon77 thanks deleted 3 of the 4 bindings to constrain variables. I take from this those with a group matter bulbs that would like to bind them to single switch will likely have issues doing so?

@Luxni ACL written to the target device successfully. Will check the debug panel when off of work.

to be clear neither bulb (aqara/Nanoleaf) is physically connected to the switch and separately powered from a wall outlet. The vtm31 is controlling both using bindings when the switch paddle is physically pressed. The switch controls neither bulb (dim or on/off) when manipulated virtually via HA or apple home.

Can this be used to bind two inovelli vtm31 white dimmers to each other? Right now I'm using automations for some multi way switches, but would love to use matter bindings.

Thank you so much for adding this. I think it closes my original feature request #815

@harryh What you mean by "binding tow dimmer switches together"? What exactly you want to achieve? Normally bindings wrong from switch to "light bulb" (in that case)

@Luxni ACL written to the target device successfully. Will check the debug panel when off of work.

to be clear neither bulb (aqara/Nanoleaf) is physically connected to the switch and separately powered from a wall outlet. The vtm31 is controlling both using bindings when the switch paddle is physically pressed. The switch controls neither bulb (dim or on/off) when manipulated virtually via HA or apple home.

I am fairly confident (but not 100% confident) that when pressing the on/off or dim control via HA, the switch does not send messages to the bound target. I set up bindings manually (via this script, but also via chip-util previously), and I get the same experience. Pressing the physical paddle controls the bound light perfectly. Sending the switch a message to turn on/off/dim does NOT control the bound light at all. I think that may be an Inovelli problem/choice.

@araemo
since reporting this early on, we have learned this is expected behavior with matter bindings as they are setup in the current matter spec, not just an inovelli issue. Neither intuitive nor optimal at the moment. see the discord discussion below.

https://discord.com/channels/330944238910963714/1368077978319327323/1397949338876903545

Wouldn't the bound switch just be another client like any remote controllers for the light.

e.g. no smart light switch involved, if I use Google to turn off a bulb, then HA bound to the same light will listen to the off signal and know that it has been turned off.

A smart light switch should work the same, i.e. it binds to the light, so if something else turns the light off (Google or HA), then the switch listens to the event and can respond appropriately, e.g. if it has a status display on the button it can change that to reflect the status.

There should no longer be any need to send a message to the switch as the switch is now a controller (not a target).

@araemo

Re "pressing the on/off or dim control via HA, the switch does not send messages to the bound target. "

I think you confuse features. The python matter server acts as a controller. So when there is a device that can be controlled e.g. onoff then you get such an entity and you control this device. Done!

Binds are a Matter feature for other nodes in the matter system like a light switch(e,g, the innovelli switches) that can directly control "Bound devices" without the need for the controller to do anything. Setting up a binding defines a "direct communication route between matter nodes.

This means that HA with the python matter node never will use the bindings itself. It will allow you to set them up for all devices in the matter fabric.

@araemo

Re "pressing the on/off or dim control via HA, the switch does not send messages to the bound target. "

I think you confuse features. The python matter server acts as a controller. So when there is a device that can be controlled e.g. onoff then you get such an entity and you control this device. Done!

Binds are a Matter feature for other nodes in the matter system like a light switch(e,g, the innovelli switches) that can directly control "Bound devices" without the need for the controller to do anything. Setting up a binding defines a "direct communication route between matter nodes.

This means that HA with the python matter node never will use the bindings itself. It will allow you to set them up for all devices in the matter fabric.

To be clear, I am not expecting HA to 'honor' the binding or use it. I would expect if I turn on the switch, that the light turns on. Regardless if I turn it on by pressing the physical button or the HA button. (And to be very clear: I would expect the switch to send the message to its bound target, not HA) I see the comment above that the matter standard explicitly says that shouldn't happen, but that is not what I expected. (And even though I don't have experience with zigbee bindings, I gather that zigbee bindings DID work that way, since other people with zigbee experience are also surprised by that)

@araemo I still do not get exactly what case you describe. If you have the light bulb in HA then controlling onoff should talk directly to the device and control it.
If you have a device that represents itself as a "Generic Switch" device type then you only get informations about how the switch was used but you can not control it yourself! So a Generic switch is kind of "read only".
If the "switch device" is a "onoff Switch" Matter devicetype then the controller does not now anything about state of on off and also can not control anything because these device types are supposed t only work via bindings.

So ... What exact case you have and what works how and what did you expect to work which does not work?

So, for example, I have an inovelli VTM-31-SN (their matter/thread dimmer switch), and bound it to an inovelli VTM-36 (the lightfan module, the switch is bound to the light endpoint, not the fan endpoint).

The two things that go 'wrong' if I control the light directly from HA/other fabrics, instead of controlling both the light and the switch:

1. The switch has an LED bar to indicate the light state and brightness level. If I send a command to the light directly, this LED bar is not updated with the light's new state.
2. If I use HA/another fabric to turn the light off, but do not also send an 'off' message to the switch, the switch's on button doesn't turn the light on. Probably related to 1, since it seems to be based on the switch's tracking of the light's state.

If these two facts are due to how matter/thread is supposed to work, I would think instead of adding the light itself as your controllable entity, you'd want to add the switch as the controllable entity, and let the binding make sure they stay synced.

But since that doesn't work, it is just a bad experience. I've grouped the switch and the light in the same room in other fabrics, but since my main control is voice control from google home, I just put both in the same room and google home tells me 'two lights on' or 'two lights off' when the 'two lights' are the switch and the light.

I do think it would be more logical for the light to be able to inform the switch of state changes, and have the switch update its LED and internal state tracking to match, instead of getting out of sync and no longer controlling the light properly. But as it stands now, it's just a poor user experience. (And to be clear, I'm not blaming HA for that, I'm blaming inovelli and/or the matter standard)

@Apollon77 I originally reported this and have had similar difficulties conveying the issue.

Users will expect that (once bindings are established between Switch A and Bulb A) Bulb A always mirrors the state of Switch A. This is how Zigbee bindings work. That is not always the case currently in Matter bindings.

Matter Bind Bulb A to Switch B On/Off and Dim

• Physically press Switch B on/off/dim actuator State of Bulb A tracks/Mirrors the state of Switch B. expected behavior
• Virtually control Switch B on/off/dim State of Bulb A does not track/Mirror the state of Switch B when the switch is turned on/off/dim by a Matter controller.

Not much you are anyone can do about it at the moment. Just more for awareness this discrepancy will be reported as a Bug repeatedly by naive users that will expect different.

@araemo Ok .... I think you have some mis-assumptions.

1.) The controller will control the light point. IF the switch has an option to visualize the light state then"the switch" (!) need to take care about that itself, because the switch should never rely on himself being the only source of control. So usually such a switch needs to subscribe to the relevant data of the light bulb directly in order to get updates on state change when it is bound to such another device. This means I see this "state not being updated at the switch" a Bug from the switch, not from anything else. So that would be atopic to give Innovelli feedback about.

2.) basically the same. If the switch relies on being the only controller then he assumes the state wrong if he did not also have subscribed for data updates. So same as 1.) in my eyes

@A-vesalius First of all please change the wording because Matter does "Bind the switch to the light Bulb" (switch this the source of control and the Light bulb the target).

In Matter a Binding basically just allows the Switch to control the light (or a group of lights). The light itself is not really involved in the binding other than allowing the switch to also send him commands or to subscribe to data.
This means - as already described in the last post - the Switch as the "source" is responsible to do what the user needs. If this includes knowing the state of bound devices (easy for a single device, impossible for a group BTW!) then the switch needs to subscribe to the device for changes and read the state or such.
A switch could also be "dumb" and always send "toggle" to the light and ignoring (and not displaying) the state ... also an option :-)

If the switch "assumes" device state then tbh this is a wrong approach because in Matter this can never be assured - and honestly in many cases not ... think abut multiple switches controlling the same light, or occupancy sensor is involved or or or ... So assuming the state is in my world just misleading.

@araemo Ok .... I think you have some mis-assumptions.

1.) The controller will control the light point. IF the switch has an option to visualize the light state then"the switch" (!) need to take care about that itself, because the switch should never rely on himself being the only source of control. So usually such a switch needs to subscribe to the relevant data of the light bulb directly in order to get updates on state change when it is bound to such another device. This means I see this "state not being updated at the switch" a Bug from the switch, not from anything else. So that would be atopic to give Innovelli feedback about.

2.) basically the same. If the switch relies on being the only controller then he assumes the state wrong if he did not also have subscribed for data updates. So same as 1.) in my eyes

So, would you say the correct process is:
When the switch is configured to bind a specific endpoint to a target endpoint on the light... should the switch automatically subscribe to updates from that endpoint somehow?

Or is that something that should be configured by the matter controller at the same time it sets up the binding?

Given that the bindings are configured by the matter fabric controller, and I assume (there I go again...) that the switch is simply parsing that binding list when it performs an action, to know where to send its commands, I would think any notification from the target (the light) to the switch would also need to be configured on the light side in the matter configuration. Like how when you configure a binding, you need to configure an ACL on the target to allow the commands from the source device, I would expect a 'binding' or something similar on the light to send notifications to the switch (And I in fact looked for a binding cluster on the light, but at least the inovelli one doesn't expose a bindings cluster).

Does the standard speak to this in any way? Is it even supported for a light to send state updates to a switch?

I'm happy to talk to Inovelli about this, but if this is a limitation in how the standard is written, perhaps it's more of something they simply shouldn't have included on their matter switches, if matter doesn't allow it when zigbee did. Also, their general answer for any question about bindings has been: "No matter controllers support bindings yet." So it will probably have to wait until this is fully released by HA.

This means - as already described in the last post - the Switch as the "source" is responsible to do what the user needs. If this includes knowing the state of bound devices (easy for a single device, impossible for a group BTW!)

Though I would hope for ways to define 'groups' of lights/switches that change together and expose a 'group' state... but perhaps that's too advanced/wishful thinking. (And yes, there's always the possibility one gets a command separate from a group, or is offline, or whatever... but it would be very useful in a not very complicated smart home to be able to link multiple lights into a group, and that group's state is pushed to all the lights at once, making them not controllable individually. If there is no concept of groups of lights/devices in Matter, this is a really limiting smart home standard...)

If the switch "assumes" device state then tbh this is a wrong approach because in Matter this can never be assured - and honestly in many cases not ... think abut multiple switches controlling the same light, or occupancy sensor is involved or or or ... So assuming the state is in my world just misleading.

I would agree with this statement.

Sorry, hopefully this time using your correct terminology. Matter bind Switch A to control On/Off and Dim of Light bulb B

• Physically press Switch A on/off/dim actuator controls Bulb A on/off/dim. expected behavior
• Virtually control Switch B on/off/dim does not control Bulb A on/off/dim. unexpected behavior.

Users will expect regardless of how they turn Switch A on it always send an ON command to Light bulb B (or a group) regardless of the bulb(s) current state. Same for Off commands or Dim to 50%. No assumptions by the switch just send the command to the bound bulb(s), exactly as the switch does when physically touched.

To be clear not asking for a change in current code, just trying to convey what will be a recurring misunderstanding by users once bindings get more broadly adopted, which is honestly likely a good ways off anyway as you switch to Matter.js and device manufacturers building in binding endpoints.

@araemo

When the switch is configured to bind a specific endpoint to a target endpoint on the light... should the switch automatically subscribe to updates from that endpoint somehow?
Or is that something that should be configured by the matter controller at the same time it sets up the binding?

If the switch needs the sate of the other device then the switch needs to do whatever he needs to get it. One option is a subscription. But so or so: This is completely up to the Switch. The controller can not know what the switch needs. The controller only sets up the binding to allow the two nodes to know each other and to enable permissions. That's the role of the controller in this case.
Your other assumption, that subscriptions or "notifications" are also configured, is wrong. Matter is not allowing this. The Switch need to do a subscription if it needs data.

I would hope for ways to define 'groups' of lights/switches that change together and expose a 'group' state ...

Matter has groups (and the OHF matter server will in the future also allow to configure them) but group state is not part of the matter standard. So group commands is kind of an "fire and forget" method.

@A-vesalius

What you mean by "Virtually control Switch B"? This depends on the matter device type you mean.

If the device type is a "generic switch" then you simply can not virtually control the switch, but this is also not possible to bind.
If your device is a "OnOff Switch" or "Dimmer Switch" device type (which can be bound) then there is also no way to "virtually control the switch" because this is not included in the device type capabilities.

Or what device type you exactly talk about? Normally you control the device (light) directly with an controller and do not "virtually control a switch" because usually that's simply impossible. So without more exact information what device structure which endpoints and such you talk about it is a purely theoretical question which does not apply in Matter reality for me tbh.

@A-vesalius

What you mean by "Virtually control Switch B"? This depends on the matter device type you mean.

If the device type is a "generic switch" then you simply can not virtually control the switch, but this is also not possible to bind. If your device is a "OnOff Switch" or "Dimmer Switch" device type (which can be bound) then there is also no way to "virtually control the switch" because this is not included in the device type capabilities.

Or what device type you exactly talk about? Normally you control the device (light) directly with an controller and do not "virtually control a switch" because usually that's simply impossible. So without more exact information what device structure which endpoints and such you talk about it is a purely theoretical question which does not apply in Matter reality for me tbh.

Crazy this is so hard too communicate this.
Virtually only in the sense I am not physically touching the switch. Simply meaning open HA, Apple home, etc and turn the switch on from that ecosystem gui.

Matter bind Switch A to control On/Off of Light bulb B

• Physically press Switch A on/off actuator controls Bulb B on/off. expected behavior
• Turn Switch A on/off with HA GUI does not control Bulb B on/off. unexpected behavior.

@A-vesalius

In the current HA, if the device is a matter light switch device, It should have no Controls.

May I ask how you control the switch device and make it send commands to the 'light' device?
Could you let me have a look at the information of your switch device in python-matter-server?

@A-vesalius

In the current HA, if the device is a matter light switch device, It should have no Controls.

May I ask how you control the switch device and make it send commands to the 'light' device? Could you let me have a look at the information of your switch device in python-matter-server?

I no longer have the inovelli switch and the aqara/Nanoleaf light bulb connected via matter bindings.

Understood.
It's a custom device.
It seems that the corresponding logic needs to be added in the HA to solve this problem (this is how I handled it on HA core).

light control is endpoint 1, associated with bindings in endpoint 2

The hidden light switch is endpoint 6 and corresponds to a multicolor LED strip built into the wall switch faceplate. No binding cluster for this.

https://inovelli.com/collections/smart-switches/products/thread-matter-white-series-smart-2-1-on-off-dimmer-switch?_pos=1&_fid=18a0ff351&_ss=c

It's up to the device manufacturer to fix the problem.
It doesn't seem like an easy job.

@A-vesalius
Ok when you use HA and control the light bulb directly then you are not "virtually" or anyhow "controlling the switch" ... you control the device directly. The switch has no role when you control the device directly. And then we come to all infos I already posted above in response to @araemo ... IF the switch need to know the status of the light then THE SWITCH needs to subscribe to it.

I know that Innovelli devices are a bit special and expose several different endpoints for it's whole functionality. But then we are also at: If an endpiint does not react as you expect on your device please contact the device manufacturer.

Thanks @Apollon77 and @Luxni, sorry for the confusion caused by my nontechnical descriptions. The response that this is a device manufacturer issue circles back to 2 post on HA discord by @jvmahon in the bindings thread that implicate the Matter Spec. I obviously do not understand the Matter protocol well enough to establish validity. Only raising this point for awareness. https://discord.com/channels/330944238910963714/1368077978319327323/1397949338876903545 & https://discord.com/channels/330944238910963714/1368077978319327323/1397950613471367249

I"m a bit late to this issue on bindings, but I do not think it is a bug.

I'll explain with respect to Inovelli switch endpoints ("EP")). I'm > 95% confident what I say below is correct based on the standards.

Starting with EP 1: note that EP is a dimmable light device. type 0x0101. The Matter Device Specification version 1.4, Section 4.2.4, shows its permitted clusters. Note the absence of a binding cluster (I'll address that in a second post). Also, the device type 0x0101 clusters are in "Server" mode. In the matter specification, "Server" means the cluster can respond to commands, from a controller, like Home Assistant, but they do not generate commands. So, as a starting point, based on the Mandatory cluster requirement for the light device type, no commands can be sent from EP 1.

EP 2, on the other hand, is a Dimmer Switch type 0x0104. This is poorly named and it would all be much clearer if it was called a "Dimmer Controller" because, in fact, it acts as a controller. Now look at the Matter Device Specification version 1.4, Section 6.1.4 which shows its cluster. In this case, the clusters are in "Client" mode (except Identify which appears as both Server and Client). In the Matter spec, a "client" cluster is one that sends a command to a server asking the server to do something. So, in this case, endpoint 2 acts to send control signals to other device. But, other than Identify, it lacks Server clusters so it does not respond to commands.

Thus, the starting point is EP 1 and EP 2 have very different functions and are independent as they have completely different cluster types (client versus server).

Now, let's look at the Binding cluster. This is needed to "bind" to other devices. To see when an endpoint can have a Binding cluster, you need to look in Section 1.1.7 of the Device Library Specification. The Binding line shows that including a Binding cluster is in "Conformance" with the standard if it is on a endpoint that is both "Simple" and which has "Client" clusters. ("Simple & Client"). So, as EP 1 clusters are "Server", it cannot have a Binding cluster and, thus, cannot be used to bind to and control other devices.

Thus, EP 2, and only EP 2, has client clusters that can be bound to and send commands to another device, and the binding cluster is on that endpoint; thus EP 1 and EP 2 are independent by design, and its not an Inovelli bug. This independence is why remotely changing the setting of EP 1, the light, does not cause EP 2 to do anything.

So, one might ponder, why not just combine the clusters of EP 1 and 2 having a "mega-EP" where everything is both server and client. Well, Section 9.2 of the Matter Core Specification says you cannot put two Simple device types on the same endpoint unless the clusters of one of them are a subset of the other. That subset requirement isn't met for the device type 0x0101 and 0x0104, so combining them on one EP is not permitted. And I'd say that trying to get EP 1 to somehow activate EP 2 would be an "end-run" around this requirement which I'd imagine would create a device certification risk.

My conclusion: encourage vendors to implement the Group cluster which gets most (if not all) the desired function; if a change is needed on the Binding side, that should be worked by chip vendors through the standards process, and not independently as a "custom feature" due to risk of unpredictable behavior across vendors.